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(57) ABSTRACT 
A system and method to enable the secure transfer of 
information between nodes in a workgroup over a public 
network by facilitating the creation of a virtual private 
network (VPNJJThe system preferably includes at least a 
pair of nodds and a VPN server. The system preferably is 
centrally managed such that when an attribute relating to a 
node or server is revised, the configuration information 
related to that attributed is updated at each node within the 
VPN. The system further preferably includes a datastore 
finked to the server and a client application located at each 
node. 
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METHOD AND APPARATUS FOR DATA 
COMMUNICATION BETWEEN A PLURALITY OF 
PARTIES 

[0001] This application is a continuaLion-in-part of U.S. 
application Ser. No. 09/640,795 filed on Aug. 18, 2000, 
which is hereby incorporated by reference. 

I. FIELD OF THE INVENTION 

[0002] The present invention relates to a system and 
method of providing secure communications over an open 
network, and more specifically to=establishing-a=.virtual=a 
private^network-fVPN^which runs across a diverse set of 
operating systems and hardware platforms and facilitates 
ease of use. 

II. BACKGROUND 

[0003] Workgroup computing involves, by definition, the 
exchange of data between the nodes of the workgroup, a 
node being a computer connected to a network which can be 
identified with an individual, a set of resources (files, 
services, devices, etc), or a gateway. Often, the tasks of a 
workgroup arc of a sensitive nature containing, for instance, 
confidential data on finances, business development plans, 
or private email. The Internet (and its native IP protocol) has 
become ubiquitous as a means of connecting nodes in a 
workgroup computing environment. However, with the 
adoption of the Internet and its public networking infrastruc- 
ture comes the risk that an unauthorised 3 rd party with access 
to the data route between two nodes may intercept and 
reconstruct data transferred between them. To prevent inter- 
ception, a mechanism is required to modify the transmission 
of data such that only the intended receiver may interpret it 
and the receiver can be guaranteed of the data origin and 
integrity. 

[0004] A virtual private network is a logical entity con- 
sisting of multiple nodes having a secure communications 
over an open and typically insecure network such as the 
Internet. Data security is commonly achieved through the 
use of cryptography, which requires the data traffic to be 
encrypted at the sender's end and then decrypted at the 
receiver's end so that other users of the public network can 
intercept the data traffic, but cannot read it due to the 
encryption. Data encryption also allows the receiver to 
verify the integrity of the data received and therefore detect 
3 rd party data tampering. 

[0005] A typical VPN connects one or more private net- 
works together through the Internet. Generally, the network 
on either side of the Internet has a gateway and ^singlg? 
a^esszconneciionzto.-^e^telnet. To create the VPN, a 
secure communications path between the two gateways is 
formed such that the two private networks may communi- 
cate with one another. 

[0006] In order to establish secure communication 
between any two nodes on a VPN, each-node^pblainB' by 
some means information ("configuration^ ) including but not 
limited to: 

[0007] Thezidentily^and state of the remote nodes 
within the VPN 

[0008] The relationships between nodes (VPN topol- 
ogy) 


[0009] Cryptography for authentication and data 
communications encryption between nodes, for 
example the key for a VPN based on shared secrets 
or certified public key for VPN utilizing Public Key 
Infrastructure (PKI). 

[0010] c Secured-communication "between~ two~nodes,is^ 
.commonlyrcalle^^a^IfunneL , , while nodes themselves are 
l often-referred-to-as-' tunnel terminators'. Traditional VPN^ 
solutions are comprised of a number-of-ti mneBennination'tt 
devices,- wych;provide-a-cejtt ral^h^ 
cation; Software is then deployed to nodes that wisrTto 
participate in a VPN, and theisoftwaie:is:configuredjnanu^ 
all y with-the-ad dress^oj-t^yP^eyice^s). The software is 
then executed in~673er to participate in the VPN. However, 
there are several disadvantages with respect to this technol- 
ogy. In general, a VPN does not allow for automatic con- 
figuration of nodes for VPN participation as nodes change 
their network addresses on being dynamically added/re- 
moved to/from a VPN. In addition, each of the nodes may 
only be a member of one VPN at a time in the majority of 
implementations, which limits the ultimate efficiency of the 
user at each node 

[0011] The use of VPN's is well known in the computer 
world each using different mechanisms to provide a means 
of secure data transmission. U.S. Pat. No. 6,061,796 entitled 
"Multi- Access" Virtual Private Network describes system 
and method for allowing private communication over an 
open network. This system however, specifies what mecha- 
nism protocol level the Agent (VPN provisioning applica- 
tion) uses to intercept incoming and outgoing data from a 
node and is not designed to work with IP networks. In 
addition, it would be difficult to scale this particular system 
for large-scale use. In U.S. Pat. Nos. 5,884,035 and 6,026, 
430 data transmission is only through the domain hierarchy 
and not on a data to client application basis. In the VPN 
system described in U.S. Pat. No. 6,055,575 it notes that the 
"host computer establishes a secure communications path, 
referred to as a tunnel, through the public network with the 
remote client". This has firewall implications in that a 
remote node can rarely accept incoming connections. 

[0012] Another very common limitation of traditional 
VPNs is their inability to cross boundaries of private net- 
works linked to each other through one or more Network 
Address Translation (NAT) devices. In addition, existing 
VPN do not facilitat e-the"Use~of end=to^end-securit vTn~tfee 
presence-of-firewal^gate^ys^ia^^ NAT 
devices, 6oth regular and PAT are very widely deployed to 
allow for better security by hiding details of private network 
from the outside world and to facilitate conservative. use_of 
public, I Headdress es J^y_mappjnR.multiple. payate,add re^s 
onto s_ingle 0 p.ublic s one^«With the growth of the Internet and 
delated introduction of version 6 of IP protocol (Ipv6), more 
and more companies will be forced to use NAT devices as 
IP address space available for general public becomes 
increasingly exhausted. The above-mentioned limitation 
arises because a NAT device modifies the data packet to 
allow for proper routing both inside a private LAN and in the 
outside world. However, any change to the packet is treated 
by tunnel terminators as a tampering, thus packets under- 
going NAT processing are discarded as damaged. 

[0013] As it follows from known PAT functioning prin- 
ciples, the presence of post-IP header is a necessary condi- 


10/20/2003, EAST Version: 1.04.0000 


US 2002/0124090 Al 


2 


Sep. 5, 2002 


tion for the packet to be translated by the PAT. Also, since 
a PAT device maps all internal nodes onto a single IP 
address, it creates and maintains internal associations 
between IP address and post-IP header of the internal node 
and its translated post -IP header. This means that traffic 
traversing PAT device and destined for an internal node 
requires a proper association to be in place to facilitate the 
reverse mapping. In other words, any post-IP session 
between PATed and external node may only be initiated by 
the external node. 

[0014] It is an object of the present invention to obviate 
and mitigate at least some the aforementioned disadvantages 
of the prior art. 

III. SUMMARY OF THE INVENTION 

[0015] Accordingly one aspect of the present invention 
provides a system for faciHtatmg:the:seciirc:a3mmuriicatiori^ 

cb;etween:nodes:irPa workgroup bv the creation of an_^ nll- 
ti ered virtual private network (WNT^ Eachinodeipreferably?] 

jias~the:ability?krtr 

public network:suc h-as-the-Interne l. Thejj ystem-com pri 
^atrleastiazpairioftnodes, a :serye r, aidat astorerlink editorthg 
(jserv^ry (where the datastore may be in the form of memoryj 
a disk, a database etc), and a^jl&nt^applica tionicapableiqf* 
cprnmunicatingLwith-the a nd s ecuring:IP^levefc?) 

g^ectiqns ctowa^ 

<protc^I%>for example~arTd~IPSec p761ocoirinrparticular an 
ESP-protocol. TtieTdatastoTe3iiftte 
pertaining-to-thezconfiguration:of^Ws, VPNrelationshi ps ' 
(e.g ^client computer_membership to VPN is),. settin gs and. 
option s (e.g. JP Sec ciphers to use ), autHelific^tion^infong^ 
Uon? and objects and attributes (e.g. status— online/offline, 
human-readable node description, node IP). cThe_system^> 
furmeirmc lude^-a-means-to-intercept-botrFmcomin g-ancbp 
<ojUgoingidatarfromra~rioli^ 
belweenzaiizoperiznetwor^ 

Hecryp tingg^T'Iiradclition , the system includes a means for 
verification oFnode credentials against authentication serv-cr~\ 
ers^^e:turinel:enab.les:data;to_be:^ 1 

[0016] The present invention is designed to facilitate the 
aspects of VPN functionality including but not limited to: 
securing communication within the VPN and VPN configu- 
ration for the exchange of secure information between VPN 
nodes. 


changes to a VPN e.g. a node logging off, and is informed 
of these changes in a timely manner, where the time frame 
is elected by the node. The VPN server then relays this 
information to each node within the VPN, which in turn is 
putting its self, the VPN server, in sync with the system. 

[0018] This system-isj5lo]jaj^y::thei 
such that it facilitates the central management of any VPN. 
The server facilitates the ability to make changes to a VPN 
without having to effect changes manually at each node of 
a virtual private network. A change made to the datastore 
linked to the server is transmitted in a timely manner to all 
client computers effected by the change. For example, to 
change the password of a VPN for each node in a network 
requires making that change to the datastore and, in turn, that 
change is transmitted to each node on the virtual private 
network. While changing a password is a relatively simple 
task, the ability to effect more detailed changes to a VPN 
requires updating only a single point in a VPN and then 
transmitting that data to the remaining nodes in the work- 
group via the secure connection. In use, the network 
includes the ability to automatically and securely provision 
security associations between nodes. 

[0019] The control of the VPN created using the VPN 
server may be in house in the sense that, at a particular 
company subscribing to this service, an IP manager would 
^administer and maintain the VPN and have rights to modify 
information on the server and datastore-as-itpertains-to-their** 
VPN. Generally ,^lR^tfaffic:betwe en-two-nodes-on-a-VPN~is° 
^ncrypted-and-decr ypted-regardless.of-^ 
^tionl Seing^p Sent. (n^_o^isjoji-as-to-secure~the-chajmei^ 
Jjetween-two-nodesjjw notriS- mjdej> v3^N:se^ 
^the_^^^gyj^configuratibo^of-the-VPN. cFhe server itself 
however, does not participate in node-to-node data transfer. 


[0017] In another embodiment, onZstart-u p^f— a-^nod? 7 
wjthinzt heisysje m, <the:; cHentif( jrjgs^ 
V Pf^seryer^ ulh eBticaUon.ctedentlals^a^ 
\SNje7yer,.^ vjere"they are va hdatedi and~a~coiu Tecjjon-i&, 
^stabl ishedz ^ollowjng^he-creation ofzaiseau'erconnectioa 7 
beJween4he-VPN.server.and ajiojje, tjb eicUenta pplicationls 7 
syncjuxmizecifw^^ 

,cessin g-initial~configuration informat\qn. This i nformation 
includcslOsXof^WNAs,^ 

member, their respective attributes, a^isting-of-other-noo^s 
wmch~are-members-of-the-same^PNs^a^he-clie¥t-com^ 
putej, the current status~of each node~in each respective 
VPN, and other related details. Once a node is logged onto 
and synchronized with the VPN server its client application 
sits in the loop so as to maintain the node in sync with the 
rest of the VPN by sending and receiving status and con- 
figuration updates to/from VPN server. The central manage- 
ment of the system enables the server to be informed of any 


[0020] This invention further provides a system to^enable^ 
^ secure ^c^mumcatiQn:betw.e I 
have- the^enefit ofgndzto^jQ&secinaLy. Iliis^S ystem iejiahkso / 
a^notieTwhiiej£may^ \ 
a firewall, ctoiestaDlish^pd^use^secureico^ \ 
therlnternet^ith"-^ general, there are two \ 

different types of Network Address Translation (NAT) 
devices — regular NAT and Network Port Address Transla- 
tion. The difference between these two types is that a regular 
NAT device uses IP header information to relay packets to 
and from members of a private group. Network Address Port 
Translation uses an IP and transport layer protocol (TCP/ 
UDP/ICMP) header. This is also referred to as PAT. 

[0021] The system comprises at least a pair of nodes 
belonging to the same virtual private network ^-a-packet-y 
intercepripj^gfichajiism ^a- secure4 ine-for-communi catior rto^ 
f the~yPN~sefy er, aji d^a^cTie n t-app licatton -Ioca"Ced~at~e ae^ 
^node. The client application located at each node includes a 
mSchanism to-encryjpt, ^decrypt or process data exchanged 
within the virtiiaTprivate network, and a software module 
responsible for maintaining configuration information 
including VPN relationships, a uthenticatk«*-info rmation, 
and settings and options. In addition, the configuration 
information indicates the presence of a NAT device, firewall, 
gateway, and proxy server in front of particular nodes in a 
VPN. The system further comprises a mechanism for^yeri- 
fication of node credentials against authentication-servers,* 
which enables data to be securely shared amongst members. _ 
ofT private group. The packet interception mechanism is 
generic and known to one skilled in the art. 
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[0022] Once nodes are logged onto a VPN, they may 
exchange information. Outgoing data packets are inter- 
cepted and then those destined to a specific VPN node are 
selected for further processing. When ongoing data packets 
are intercepted, the VPN indicates the presence of a NAT or 
PAT device, a firewall, gateway, and proxy server in front of 
the intended receiving node. In order to facilitate data 
exchange to nodes located behind one of the above-men- 
tioned devices, the-data ^pAcket r headerTis:mojdifiedT The data 
packet itself is encrypted as a whole and a new header is 
prepended to the now encrypted data packet. Source and 
destination node information is added to the prepended 
header and is determined by the VPN. The new header is 
referred to as an "external header" and the original packet 
header is referred to as the "internal header". The external 
header contains a masquerade bit which allows the receiving 
node to recognize the modified data packet as having a 
prepended external header. Once the data packet traverses 
the device, the external header is removed and the packet is 
processed according to the specifics indicated by the original 
IP header. 

IV. BRIEF DESCRIPTION OF THE DRAWINGS 

[0023] These and other features of the preferred embodi- 
ments of the invention will become more apparent in the 
following detailed description in which reference is made to 
the appended drawings wherein: 

[0024] FIG. 1: is a schematic diagram of an overview of 
a computer system; 

[0025] FIG. 2: is a functional block diagram detailing the 
method for establishing secure communication between 
nodes, in the computer system of FIG. 1; 

[0026] FIG. 3: is a schematic of the computer system 
incorporating a plurality of types of nodes; 

[0027] FIG. 4: is a schematic diagram of an overview of 
a computer system incorporating LAN's, a gateway, and a 
firewall; 

[0028] FIG. 5: is a functional block diagram detailing the 
method for sending data over a VPN having secure com- 
munication in the computer system of FIG. 1; 

[0029] FIG. 6: is a functional block diagram detailing the 
method for receiving data over a VPN having secure com- 
munication in the computer system of FIG. 1; 

[0030] FIG. 7: is a schematic of the data packets trans- 
ferred between a plurality of types of nodes on a VPN; and 

[0031] FIG. 8: is a schematic diagram of an overview of 
another embodiment of the computer system of FIG. 1. 

[0032] To facilitate the understanding of the preferred 
embodiments described below, the following terminology 
will be used, it being understood that this is for illustrative 
purposes only and is not limiting: 

[0033] Client Application — the software that acts as a 
slave to a server and is present on each node within 
a work group; 

[0034] VPN — a virtual private network that is con- 
structed over a public network to connect nodes 
within a work group such that: 


[0035] a) data transferred between those nodes is 
secure and cannot be intercepted, modified, or 
replaced on route; and 

[0036] b) it contains mechanisms to ensure that 
only authorized users may access the network. 

[0037] Node — a computer connected to a network 
which maybe identified with an individual, a set of 
resources, or gateway; 

[0038] Work Group — a group of two or more indi- 
vidual nodes working collaboratively on a group of 
tasks; 

[0039] Gateway — a special node that provides secure 
communication to a specific network of nodes 
located behind the gateway; and 

[0040] Network Address Translation — (NAT) an 
Internet Standard that enables a LAN to use one set 
of IP-a ddresses for inleTpTOnffic and a s econd set-of-^ 
ao^e ^s-toT^xler^aFtra|ric^ 

V. DETAILED DESCRIPTION OF THE 
EMBODIMENT 

[0041] A system and method for^e^ablishing^^'cujc 
CcjQHMction:for:the^ 

.group-o ^er'arp ubHcinetwjorkzisziHustrated in FIGS. 1 
through 8. The computer system is generally designated by 
reference numeral 10. The system 10 may be configured in 
a number of different ways including those utilizing indi- 
vidual users as shown in FIG. 1, those utilizing individuals 
and intranEt as shown in FIG. 3, and those utilizing a 
gateway as shown in FIG. 4. clm^Jtylitlis^^^^gCCS^ 
ejstabUs h-ggnfflurication^ 

vJt|In£iworlt?(VPN)"arId this procedure will be described in 
respect of elicrTcc^figulrationr ' " 

[0042] As shown in FIG. 1, a computer system 10 com- 
prises a plurality of]nodesjg;(client computers), serverlS^y 
and ^-datastore!2iF whose contents may be updated or 
changed periodically by external intervention. Server 18 is 
also referred to as the VPN server however, it is understood 
that the VPN server is capable of performing typical server 
functions known in the art in addition to the proyjsioiiingrcf' 

£a3jEN2s is described below. ^acK^fltheznodes^lncluites 
^cKeftt~a p pfication^ 4:icapabler^ 

^server^8. The system 10 is arranged to-enable^theiestafe 

f2 .over-a -public n etworfeu<^^S' fe"Intemgr2 2 . The~server~7 
^H^coMeejfe andj^ fetributc^data^ol lected ~b y~the~~clie7 it 
(a^hca^ti olFr4^t~each~node ^-^, so as to maintain state 

information for each node 12. The"server48-tracks-chan ges/ 

made~to-thedatastore~20;and subsequently updates each of 

the node]T12rThe-clienT^ppi^ 
ctransmittmg -iriform^ 

( £^e^ndicjient:applicationrl4:of:arnode^2 aiidrScrver-18*? 
The server 18 also serves to generate specific node cues 
based on those events, such as the availability of upgrades 
for client appucation^Thejda^asioj^^ 
18£aj^riOnanage^^ 

cingTof^ecurityl^ A 
network having secure communication between these nodes 
12 is typically known as and from herein referred to "a 
virtual private network" (VPN). The centrally managed 
system 10 allows for arbitrary additions, modifications, and 
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alterations to the datastore 20 and, in turn, deploys that 
information through the server 18, to nodes 12 located 
within a virtual private network. 

[0043] The method of ^e^ablisjn^^ ^ure mmmunicaticn F 
between-nodes-m-a ^worl^ groinj-i s detailed-in-H G. 2. Qn, 
( startu^fXn^^ 
l^mstrucls^e.node-12-to^^ 

18rOnce the~instructions have been received, as indicated at 
102,^ ~socketconnection is'foM 
^li^mdjjcry^r 18 (generally using secure socket links such as 
SSL/3DES socket security). <Once=the=eonnection, 104, is 
ioxmed .between itherserver-and-the^node , the^authep ucatioo 
phase^l06rbegihs^ The client application transmits creden- 
tials to the server 18. The server 18 then authenticates the 
validity °of these credentials and returns data stating the 
success 108 or failure 109 of the logon to the server. If the 
credentials are found to b e invalid the proce ss fails and ends. 
^nc^hlFno^iF^ 

eonnecuon:is"formeS? the synchronization phase 110 begins. 
<The^r^r-18:delivers:a-,pac^^ 
h'olfrtO^the^lient 3 ^ 
soekebconnection^so^as^^^ 
^wdrlc^The configuratidnal information ifeludesrr5ut~is~hot ' 
— fimited.-to, a^ist-oflvirtual-privaje-ne^^ 

node-is-aj™^Trrth'eir _ relafe3 attributes, the state of other 
nodeslocated within a VPN of which the node or client 
computer is a member, an d-their related-det a ils-such^a sj^p 
^adcfcess.<Onc^th"is^tr^ 
^fllejem^ 

^ated^arll^and:meTaKlity:to:tra 

of^ mmunica tiQnris^enafeled. Once^^Hodeislogged onto ftie — * 
<£ serverja8 , dataris:transferred:between3aipair:of:nodesrl2:by^ 
^voking:procedureson:remotelv-hc^ted;appHcatio nson-the-^ 
< nodejL2^and determining the type and target of the change 

or data to be distributed. 

[0044] The system 10 is global by nature such that it 
facilitates the central management of the VPN. Tbe=system==> 
l O/CTables each jiofe:12zand:sery^ 

change to the VPN by updating a single point within the 
VPN and transmitting that data to all affected members of 
the VPN. Once a node is logged on to a VPN, thereafter, any 
change to the datastore 20 that affects a work group of which 
the node 12 is a member will be^forwarded^from-the^server^ 
18 tp-that^ode. The server is able to determine the relevant 
nodes 12 from the contents of the data product received 
during the information transfer phase 112. There are two 
types of changes that affect the datastore 20. A no de^gen^ 
erated-cha n ge-e:g:/going-qfgjj ie, invokes an applicatioij 
located on the server 18 to change the attribute of "itself". 
The server 18 examines the type of change, in this case — 
going offline, and determines all online nodes in the VPN's 
that the node is a member of which require notification. 
s€ Tver::18zretoeyes;arlist-o£mcs^ 

20, and notifies each interested node. The notification is 
either synchronous or asynchronous. 

[0045] A m anagement -interfac^' change e.g./altering VPN 
membership for example, through aiwebrbasedzconfigura^ 
tiorjLtooi 1 , myqke£^a~proge jure:on:^ 
serwr4§55tecfia^ hhe-datastoi? 20. The server 18 
examines the type of change and distributes the notification 
as described above. A ccordingly^a^VPN riszestablished-to^ 
CaUoj^communic^^ A similar 

j^oceduTe^miybe ; milized in the configuration of FIG. 3. 


[0046] FIG. 3 illustrates a plurality of nodes 12 A through 
12E, where at nodes 12C through 12E there are a plurality 
of client computers. The computer system 10 detailed in 
FIG. 3 is a multi-tiered client/server system in which every 
node 12 acts as both a client and server. A node either pulls 
update from the server, and in such a case in synchronous or 
acts as a client, or the server pushes updates to a node by 
invoking a method on an object which resides on the node, c=n 
hence is asynchronous and acts as a server. TjiezseaycrfS ^ 
. cgpex afesioye^^ I \ 

l2 jj^gAch^o:dell^ppo^e^ st 3tozcomputeesystemrl(b> 
aUows-aij?itrjuy-gro^ 

WNs^acress, for instance, network, organisational and 
geographical boundaries. 

[0047] The computer system 10 enables ah e xtranet con- 
nection for example between two oflicesofa^comr^y^l2D 
5S^Er^hT6f"wm'£^ to be 

included in a work group. In this situation a corporation 
typically will have at least one localized server 17B, 19B, 
which will act as server for that Intranet. Each node 12 


within that corporation wflfbT connected to that localized 
server. The localized server 17B, 19B exists within a hier- 
archy within the computer system such that if a node/client 
computer within the corporation queries the localized server, 
and that server does not contain the information queried fief, 
that server climbs the hierarchy chain to a higher up server • 
and queries for the information. This process continues until 
the information is returned to the localized server where it 
can be distributed to the appropriate client computers within^ 
that network. Alternatively, a node wit hin the corporate } 
^network is capable of communicating wil^tor example^a 7 

traveling* user' 12B located outside* the office. \ 
— - = ■- « ■ ■ ■ — a *** MW * M ^" < ' 

[0048] When each node 12A through 12E logs onto the 
server 18, such that each node in the network exists in a 
parallel relationship with another node. In one embodiment, 
each pair of nodes is typically setup with a set of k eys and 
a uniq ue identit y £^ghjh a t„thgy_.rn ay transmit secure mes- 
sages that have been encrypted and dpFryp^[*S^ ffisjet <i 
Of ^if'balecTl^ys" Preferably, the system 10 employs an 
existing peer-to-peer key exchange mechanism e.g. Internet 
Key Exchange (IKE), to negotiate session keys with each 
peer for data exchange. However, in the event that IKE is 
inaccessible, a pair of nodes 12 may negotiate and transmit 
keys via server 18. In the alternative, the server 18 may 
generate and distribute to keys and node pairs 12.<ItwilW>e> 
app rociated-t haHvlaenitran 

(^o^e^orOQZaiyirjalalipr^ 

r tfansmitteji:thm^ 
ct he-mitjaj ^royjtefo^ 
tra^^er^fom^ 
12?ipLnIcoffi 

^atlvirtual-Tjrivate-network. '^aiii^— Vl^^is^csiablished 

[0049] FIG. 4 again shows computer system 10, and in 
this embodiment, invol ves the ^usc^of a gateway 24 that 
includes a library portion containing attributes of the servers 
connected to the gateway 24. Although the gateway 24 
controls access to several nodes, each indicated as a server 
25, the gateway 24 is considered a node by other users 
within the VPN and typically includes a key pair associating 
it with each of the other nodes in the system 10. During the 
logon process detailed in FIG. 2, ^e^rver-18-wilhdetec^ 
the presence_oLthe_g ateway 24 an drdulinXthTs^hroni- 

,*t g^s; — J 
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zation i 


htO:the=» 


J^^a^BeGSd-the-gatcway. In an alternative embodiment,^ 
Igie^ejyeT^il^^^ 

K (shown in FIG. 4), ,NA3> box, or PAT box (not shown) as 
above. The gateway 24 includes a set^f fuJe^cjUejdsecm^v^ 
associationsjhat are designed to .controi.access.to, the3^PN.^ 
luc&nSat^ie gatewa y protects a plurality of ^des. Con- 
>emionall^when a nodeTin front olf the ga^wayT such as 
12 A wishes to communicate with a node behind the gateway 
such as 12G, the node 12 A selects the key pair associated 
with the gateway 24 to provide encryption and decryption of 
the data. The decryption then occurs at the gateway as 
opposed to at the node to which the message is directed. The 
same is true of a NAT device where decryption traditionally 
occurs at the device. When a user who is typically a member 
of the plurality of nodes located behind the gateway, such as 
a company network 12G, is j^lcingfrom Ho^^A, jflglP!^ 
atidres s~oir^:Bpr^ 

addresses spec^eyb^Ittie-gatewSV.,24. When.an,IR.address^ 
"rSfe outsio^nVr arigeof address es knowrTto t he gateway 24 
access may be denied' to tne company networkTlnsucn a 


situation .ja^ir|ual:tP^(^^ 

the^ homs~useT32A . Whena VlP "isTa^i gneSTol inTnodroT J 
tne home user 12AJ data sent:fn5fn^rlo ^l2A4o-fehe-CQro pany^ 

c netw.ork^l2<S^ lo cated behind the gateway 24, th e gateway 
wil kroute^this^data^thfou^ case 
where a node is a in tranet, as in FIG. 3 node 12C, a pd-that ^ 
node lTC wants to send data to 19B, th^scryer 1 8wSl have 
a^plu xality-of^fes4cnown-as~an-g cc^^ 

"staUng^wtacb^ieat^mputer^ 

] a^^-da jgi^n^ne^eT ^rs. Security measures in each of the 
(jBove cases conventionally are employed at the gateway 24. 
[0050] In order to employ end to end security in the 
presence of firewalls, gateways, NAT/PAT boxes, and proxy 
servers or when connections are slow and unreliable, a 
preferred procedure is set forth in FIG. 5 is utilized. On 
startup of a node 12 within a work group (as shown in FIGS. 
3 and 4), thaUiede^ornas -a-secuTe conne,c t! oI0^ 1%~ry.^ 
18jis descxEeTiFFTGr 
J02, on-sjrjclir^Su^ 

betwee jlnodss and determines the presence of NAT devices, 
firewalls, gateways and proxy servers in front of particular 
nodes within the VPN. On .assessingrxonnectisaty, 204, 
where a node is located behind for example, a NAT or PAT^-^ 
box, that ^o^gunffio^^ \ 
client-ap plication of-each-member-within-the-Vg N. Provided \ ) 
a node is not located behind a gateway, NAT/PAT box, 
firewall, or proxy server, a data packet, 9rigin aiingzfeoffl 
mdependent-appUcationvissent- securel ^^ 
to'SanotneR^ira^ 
^end-lo^d^secuj^ 

^headerj727TTCP headeF74ra"nd"aatT7(l as shown in FIG. 
TflTTOe^freade rcommunj cj^ the TCP 

header specifies the transport pro'tocol, and the data portion 
is the bit stream which comprises the message being sent. 
The actual processing of the information contained within 
the data packets, as well as the decryption, is known in the 
art and falls outside the scope of this invention. 
[0051] In the event that a device is detected in front of a 
particular node, the system 10 employs a modified method 
of communication that facilitates end-to-end security and is 
described below. The detection of a NAT device, firewall, 
gateway, and proxy server, 206, indicates to the system 10 


do invoke a modification to the data packet in order to 
[facilitate traversing of the device. Pata'packetsroriginatingy 
ironT^a^noli^ 207 amfcthose=c^ 

gackejsjiestinedito-a^ 

devic^are^leete^ r f»T^ The selection for 

further processing informs the system 10 that these data 
packets that have been intere^eiJ-requir^nra 
qr^eMoj^abJerthdr^senlling. Thus, the data packets are 
examined and packe.tzhe.aders.are^nodified 208 (as shown in 
FIG. 7) as will be described below. This masques the data 
packets such that, to the device they appear to be unmodified 
and traverse the device as secure encrypted data packets. 
The masqueraded data packets preserve the original data 
packet and h e_adefdnJ prmation as an encapsulated secure 
pay load and appends a n ew-extefl aabheader. The external 
header includes a data bit from herein referred to as a 
"masquerade bit" which acts as a "flag" or "indicator" that 
the packet header has been modified, 210. To the device, 
such as those shown in FIGS. 3 and 4, the data packet 
appears to be an unmodified protocol session and passes 
through the device unread. In the case of a firewall, (shown 
in FIG. 4) uponrreceiptatthe^firewall, the external header^ 
jsjio^ntified^a^^arFSSPand is directed to dedicated port 443 
in the wall and passes through that port without further 
examination to the intended receiver. 


[0052] In the preferred embodiment, the system nodes are 
restricted to use Encapsulated Security Payload (ESP) pro- 
tocol in tujm^xripfoBsecuxifcg data being exchanged by 
VPN nodes. This is a protocol that resides on top of the IP 
layer in network stack and thus allows for securing any IP 
traffic. A data packet secured by Tunneled ESP is encrypted 
as a' whole, and is prepended with an ESP hea deLand.a npther 
copy^rfiPJIa^ejLjvhich c6mprtses-a-TieW^xternal header. 
Source/destination node information in the new IP header 
within the external header may differ from the IP header in 
original data packet. The ESP processing setup determines 
any change to the IP header information. Original IP header 
is further referred as 'internal' and newly prepended one — as 
' external' . 

[0053] Typically, when an encrypted packet traverses a 
NAT device, for example, its external IP header is modified 
to contain proper addressjn&Mormafon. Upon arrival at the 
destination node the external IP header is stripped off during 
data processing and the external IP addressing information 
is irrevocably lost. Therefore, the receiving node is not able 
to process the decrypted packet properly. In the present 
invention, the data packet memorizing the external IP header 
prior to its stripping, and then adjusts internal IP header 
based on the network setup. For example, a data packet 
when traversing a NAT device, arrives at the NAT device 
and at this point prompts the system to copy the destination 
IP address from the external header. If, in addition, the data 
packet arrives from a NAFed node (a node having a NAT 
device in front), then the system is further prompted to 
update the source IP address from the external header. The 
IP/TCP/UDP checksums of the adjusted packet are recalcu- 
lated or turned off such that the packet integrity is guaran- 
teed by successful decryption. The centralized nature of the 
VPN supplies nodes with information about their peers that 
allows for each node to decide if a particular peer or node is 
NATed. This effectively eliminates the 'detection' (or 
'negotiation') step known by those skilled in the art and 
typically employed by other NAT-traversal methods to deter- 
mine the presence of the NAT between two nodes. The 
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process described above of changing the IP header before 
submitting a data packet to the IP processing is further 
referred to as 'RNAT transformation'. 

[0054] A data packet traversing a PAT has both its IP 
header modified as well as its transport layer header trans- 
lated. Commonly supported transport protocols are TCP and 
UDP. ICMP, while not being true transport protocol, is also 
generally provided a limited support for its ECHO mes- 
sages. Note that these three protocols are referred as 'post-IP 
protocols' below. 

[0055] In the case where a data packet traverses a PAT 
device, the system employs the following approach. Assume 
node A being PAT'ed node (a node having a PAT device 
located in front) and node B its peer residing outside the PAT 
device. In this case, node B may be located behind NAT, but 
not PAT device. A packet sent by node A is processed as 
described and above and then in turn, receives a UDP header 
and a masquerade bit inserted between IP and ESP headers 
of the encrypted packet as was described above. This extra 
step of outbound processing, including the UDP header, is 
further referred as 'UDP-masquerading* or 'masquerading'. 
The masquerade allows recipient to differentiate between 
masqueraded and 'true' UDP packets with a high degree of 
accuracy. Upon arrival of a data packet at node B having 
traversed a PAT device, the data packet UDP header is 
associated with the tunnel through which it arrived. In other 
words, it associates the node from which the data packet 
originated. Then packet is then stripped of the UDP mas- 
querade header to reveal the original header and inbound 
ESP processing and RNAT transformation is performed as 
previously outlined. The ESP code links plain text post-IP 
information to the tunnel through which it was delivered. 

[0056] A data packet leaving node B destined for node A 
is first subject to a regular ESP processing with compulsory 
Tunnel selection based on its IP and post-IP information 
stored during inbound processing. Once encryption of the 
data packet is completed, the data packet is masqueraded 
based on masquerading information also stored during 
inbound processing. Upon arrival at node A, the data packet 
is subject to demasquerading, regular ESP processing and 
RNAT transformation. 

[0057] In a further embodiment, the system facilitates a 
means to potential post-IP information ambiguity develop- 
ing on node B after packet decryption. For example, two 
nodes (Al, A2) may reside behind the same PAT device and 
use the same source port to access the same node B port. It 
this case, after RNAT is applied, data packets originating 
from nodes Al and A2 are indistinguishable and a reply from 
node B could not be routed back to the appropriate node. The 
system in this case applies a post-IP layer overloading 
(similar to the PAT) to each data packet traversing the same 
PAT device arriving through different tunnels. A PAT trans- 
formation is applied to all inbound data packets to resolve 
ambiguities and the reverse mapping to the originating node 
is performed on the outbound data packet in order to restore 
the post-IP headers to peer's expectations. 

[0058] When a node is the intended recipient and that node 
logs on to the VPN, the node receives a data packet 252 as 
shown in FIG. 6. When a data packet arrives, the intercep- 
tion mechanism (253) analyses the packet header 254 for the 
presence of a masquerade bit. If a masquerade bit is not 
detected, the data packet is received by the intended node 


262 and is processed. When a masquerade bit is detected 
256, it indicates to the system that further processing is 
required. When the received node is located behind a 
NAT/PAT box, it is the box that receives the data packet, 
analyzes the header, and detects the presence of a masquer- 
ade bit. In the case where there is no NAT/PAT box, the node 
performs the analysis and detects the masquerade bit. Once 
the masquerade bit is found, the external header is removed 
258 to reveal to original header. This original header is 
examined and the packet is routed to the intended-receiving 
node and allows for return data to be sent. 

[0059] If, in the above circumstance, the node is not 
logged on to a VPN, the packet is sent and once the peer or 
intended receiving node logs on to a VPN the packet is 
received by the peer following the procedure outlined in 
FIG. 6. 

[0060] FIG. 7 shows the transformation of a regular data 
packet 70 illustrated in FIG. la to a modified data packet 90 
illustrated in FIG. lb that was described in FIG. 7. The 
orjfflgal ^-data^ackei-70-mdude&^-IPJi eader 72, a TCP 
header 74^ and^niaTa*^po^iorP76rin order to facilitate 
end-to-end security in the presence of a firewall, NAT/PAT 
box or gateway etc, the data packet is modified/re-written, as 
described in FIGS. 5 and 6. The modified data packet 90 
comprises a new header 91 and a data payload 96. The 
header 91 of the modified packet 90 comprises an IP header 
12b y and ESP header 93 and a masquerade bit 94. The data 
payload 96 of the modified pack 90 encapsulates the original 
data packet 70. On receiving a modified packet, as detailed 
in FIG. 6, the new header 91 is removed and the packet is 
processed to reveal the original data packet 70. 

[0061] On securing a communications path over a public 
network between two nodes in a computer work group, a 
typical encryption technique used to transfer data between 
these nodes includes: generating a data packet to be trans- 
mitted over the secured communications path where the data 
packet includes routing information; encrypting that data 
packet using an encryption technique known to one skilled 
in the art; encapsulating the encrypted data packet into a 
secondary data packet compatible with public network pro- 
tocols; transmitting the encapsulated data packet over the 
public network; the data packet arriving at the receiving 
node; and that receiving node unpacking the encrypted data 
packet using a set of authentication keys, stripping the 
second data packet from the original data packet, and 
decrypting that data packet received from the originating 
node. 

[0062] In the preferred embodiment, secure IP communi- 
cation using e nd-to-e nd^sficurity^between any two^nodesJU^ 
over, the^ Internet 4 22 is established with only^jnimmal 
assumptions about any particular dole's connectivity privi- 
leges. This is accomplished by applying IPSec transforma- 
tions to incoming and outgoing IP^oackets at the transport 
layer and then transforming these processed packets so they 
appear to be an SSL protoco l session until received by the 
de stination nod e~ 

[0063] For operation within the system, the node (base 
configuration) preferably includes: 

[0064] An IP add ress and a connection to the Internet 

(may be non-unique); and 
[0065] Ability to send and receive TCP data on port 
443 in SSL format (on some servers may also require 
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the ability to send and receive TCP data id SSL 
format on a port specified by the server). 

[0066] The optimal configuration for a node (recom- 
mended configuration) is defined as follows: 

[0067] Those abilities defined in the base configura- 
tion; and . 

[0068] (^Tglobally mutable IP addr esser 1:1 static 
NAT. 

[0069] At least one node in each pair supports at least the 
recommended configuration, and the other node supports at 
least the minimum configuration. The system requires that 
only one of a pair of nodes may be located behind a firewall. 
The recommended encryption level for data in transit is 
3DES. The system, in the preferred embodiment, accesses 
both: 


(" [0070] configuration data (IP addresses, etc) provided 
\ by server, client application, and library aforemen- 
/ tioned; and 

[0071] a packet interception and injection mechanism 
partially provided by Trilogy AdmitOne 

[0072] The computer system 10 may be run on a diverse 
set of operating systems and hardware platforms such as 
open BSD, UNIX, Windows NT, Windows 95/98, Linux, 
and Solaris. 

[0073] In another embodiment, as shown in FIG. 8, a 
system 50 comprises VPN servers 44, which function as 
central policy management for establish ing and |acjy£atiag 
yPN^operati on. The system 50 turtner comprises at least a 
pair of database servers 40 and a Round-Robin Doma in 
Name Serve r (DNS) 42 in a distributed, fully integrated 
environment. The DNS server 42 assures homogenous dis- 
tribution of the data load across the VPN servers 44. 
Connectivity between VPN servers 44 and the database 
servers 40 is implemented so as to support several modes of 
communication including but not limited to open database 
connectivity (ODBC), Java Database Connectivity (JDBC) 
or any other database connectivity interface. The database 
servers 40 are mutually synchronized to keep the data 
contents current and up-to-date. The content of each data- 
base server 40 is identical such that, should one database 
server 40 crash, each of the VPN servers 44 connected to 
that failed database server 40 may automatically reconnect 
to another available non-failed database server. 

[0074] The VPN server 44 may operate in either a stan- 
dalone or a distributed environment. The nodes 12 partici- 
pating in a VPN may be connected to the same VPN server 
44, as the VPN servers 44 are synchronized such that a node 
may log onto any VPN server 44 and participate in a VPN 
of^hic^they^are a 'member. As the system 50 is fully 
synchronized, forwarding from one VPN server 44 to 
another is not necessary. Each event or revised attribute of 
a node 12 or server 44 is distributed to the entire system 50 
directly by the original sender. Synchronization enables 
VPN nodes to see one another as if they were physically 
connected to the same VPN server 44. 

[0075] The system 50 employs a variety of com munica- 
tion protocols utilized within the VP Nenvironment so as to. 
facilitate communication df'thTVPNseryer 44.a nd its node ^ 
12 acrosslhe open network^nvirohment. In the preferred 


embodiment, communication within the system 50 occurs at 
a "secure sockets la yer" (SSL) underneath any security 
attributes. The system however, further enables communi- 
cation, in one embodiment at the application layer. Such 
communication may be in the form of the following: 

[0076] a) Authentication of users 

[0077] When a VPN node 12 is going online, the node 12 
submits its authentication credentials, which are validated 
on the server side. The node 12 may enter another state of 
communication once the authentication credentials have 
been approved. The system 50 supports two ways of authen- 
tication, either using a user name and password or client side 
certificates however, authentication is not limited to these 
two types. 

[0078] b) Proxy authentication of users 

[0079] On authenticating the credentials of a node 12, the 
credential(s) is validated against an external data repository, 
for example Lightweight Directory Access Protocol 
(LDAPO, Radius, or Windows NT/2000 domain. 

[0080] c) Distribution of user state updates 

[0081] When a VPN node 12 goes online/offline, other 
nodes within the VPN are notified of this update such that 
the related security associations are also updated. Any 
further communication between VPN nodes is utilized 
through an IPSec protocol and does not flow through the 
VPN server 44. 

[0082] d) Providing a way to establish common secret 

[0083] Each VPN node 12 generally possesses a common " 
secret such as a private key which is passed to the IPSec 
layer and is used to protect the respective data traffic. This 
secret may be created by the VPN server 44 and distributed 


to the appropriate VPN node or Jhe secret may be created 
16calIy~aTthe node~121uTdlMblrIitted to a second node in a 
secure and private manner through the VPN server 44. The 
common secret for example may be a symmetric key, 
"Internet key exchange" (IKE) so as to allow secured 
nc^e^to-node^ommunication. 

[0084] e) Password exchange protocol 

[0085] The system 50 encapsulates a secure -transaction 
mechanism to allow VPN nodes 12 to update their VPN 
passwords. After a node is successfully authenticated, the 
node is allowed to submit a password change request, 
followed by the approval/confirmation of both communica- 
tion parties (VPN node and VPN server 44). 

[0086] Although the invention has been described with 
reference to certain specific embodiments, various modifi- 
cations thereof will be apparent to those skilled in the art 
without departing from the spirit and scope of the invention 
as outlined in the claims appended hereto. 


1. A method for establishing a system for secure commu- 
nications between nodes in a workgroup over a public 
network by facilitating the creation of a virtual private 
network (VPN), including a VPN server, the method com- 
prising the steps of: 

establishing a secure connection between at least a pair of 
nodes within said workgroup and said VPN server; and 
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synchronizing each of said connected nodes with said 
VPN server such that each of said connected nodes 
receives configurational information relating to 
attributes of each of said other connected nodes; 

wherein, when an attribute relating to one of said con- 
nected nodes or said VPN server is revised, said 
configurational information relating to said attribute is 
updated at each of said connected nodes. 

2. The method for establishing the system of claim 1, 
further comprising, following said step of establishing said 
secure connection, a step of authorizing, at said VPN server, 
validity of said connection between said VPN server and 
each of said connected nodes. 

3. The method for establishing the system of claim 1, 
wherein following said step of synchronizing said server and 
each of said connected nodes, a step of sensing attribute 
revisions relating to one of said connected nodes or said 
server. 

4. The method for establishing the system of claim 1, 
wherein said VPN server enables secure exchange of said 
configurational information between said connected nodes. 

5. The method for establishing the system of claim 1, 
wherein said VPN server restricts exchanges of configura- 
tional information based on trust relationships established by 
said connected nodes. 

6. The method for establishing the system of claim 1, 
wherein each of said connected nodes remains in a loop with 
said VPN server so as to forward any attribute revisions 
changes within a node to each of said connected nodes. 

7. The method for establishing the system of claim 1, 
wherein each of said connected nodes automatically pull 
changes from said VPN server so as to update said configu- 
rational information stored at said node. 

8. A system for establishing secure communication 
between nodes in a workgroup over a public network by 
facilitating the creation of a virtual private network, the 
system comprising: 

at least a pair of nodes; 

a VPN server, connected with each of said at least a pair 
of nodes for synchronizing each of said connected 
nodes with said VPN server such that each of said 
connected nodes receives configurational information 
relating to attributes of said other connected nodes or 
said VPN server; 

wherein, when an attribute relating to one of said con- 
nected nodes or said server is revised, said configura- 
tional information relating to said attribute is updated at 
each of said connected nodes. 

9. The system of claim 8, wherein said system further 
comprises a datastore connected to said server. 

10. The system of claim 8, wherein said system further 
comprises a client application located at each of said con- 
nected nodes. 

11. A method for establishing a system for secure transfer 
of a data packet between a first node and a second node in 


a workgroup over a public network, where said nodes are 
members of a virtual private network, the method compris- 
ing the steps of: 

assessing a presence of a device associated with said 
connected first and second nodes; 

modifying a packet header of said data packet intended 
for transfer between said first and second nodes when 
a device is detected; 

wherein said modification of said packet headers facili- 
tates traversing said detected device for transmission of 
said data packet between said first node and said second 
node. 

12. The method for establishing the system of claim 11, 
wherein said modified packet header comprises an Encap- 
sulated Security Payload (ESP) header, an Internet Protocol 
(IP) header, and a masquerade bit, said masquerade bit 
acting as an indicator to one of said first and second nodes 
that said data packet has been modified. 

13. The method for establishing the system of claim 12, 
wherein said masquerade bit is located between said ESP 
header and said IP header. 

14. The method for establishing the system of claim 12, 
wherein a packet interception mechanism analyses said 
packet headers for detecting the presence of said masquer- 
ade bit. 

15. The method for establishing the system of claim 13, 
wherein when said masquerade bit is detected within said 
packet header, said modified packet header is removed and 
the original packet header of said data packet routes said 
data packet to one of said first and second node. 

16. The method for establishing the system of claim 11, 
wherein said device is selected from a group comprising a 
Network Address Translation (NAT) Device, a firewall, a 
gateway, a proxy server, and combinations thereof. 

17. The method for establishing the system of claim 11, 
wherein when a device is detected, said device is located in 
front of said node. 

18. A computer system for establishing the secure transfer 
of a data packet between nodes in a workgroup over a public 
network, where said nodes are members of a VPN, the 
system comprising: 

a first node; 

a second node; 

a device detection mechanism; and 

a packet interception mechanism; 

wherein when a data packet is transferred from said first 
node to said second node and a device is detected at 
said second node, said data packet is intercepted and a 
packet header of said data packet is modified to facili- 
tate the data transfer between said nodes. 

* * * * * 
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